Hermes Kanban 多智能体协作方案详解

基于 hermes-kanban-v1-spec.pdf， Nous Research，2026年4月25日
状态：DESIGN ONLY，尚未实现

一、Motivation：为什么需要 Kanban

Hermes 现有唯一的多 Agent 协作原语是 delegate_task（同步 fork-join 子 Agent 调用），适合短小的自包含推理子任务。但以下四类场景它无法覆盖：

二、竞品教训

2.1 三个系统对比

2.2 核心教训

NanoClaw 是反面教材：在 Claude Agent SDK 非交互式 query() 模式下，子 Agent 在 team-lead 完成回合时会被静默终止——看起来成功，实际零产出。

根本原因：协调依赖于上游 SDK 的内部生命周期，SDK 无法保证子 Agent 存活。

Hermes Kanban 的设计原则：

1. 采用 Cline 的 board + links + 临时工作区形态
2. 借用 Paperclip 的原子认领 + 持久 Agent 身份（映射到已有 Hermes profiles）
3. 拒绝 NanoClaw 的进程内子 Agent 蜂群——每个 worker 都是完整 OS 进程
4. 继承 Google Gemini 的可移植 profile 产物 + @mention 委托语法
5. 拒绝 企业级治理内核——治理 = 用户空间 profiles + plugins

三、三层架构

┌─────────────────────────────────────────────┐
│           CONTROL PLANE（控制层）               │
│         用户：CLI / Telegram / Discord         │
└──────────────────┬──────────────────────────┘
                   │
                   ↓
┌─────────────────────────────────────────────┐
│             STATE PLANE（状态层）               │
│            kanban.db（SQLite，WAL 模式）        │
│  ┌──────────────────────────────────────┐  │
│  │  DISPATCHER（cron，60s 触发）            │  │
│  │  1. 重算 READY（父任务全部 done？）        │  │
│  │  2. 原子认领（CAS）                       │  │
│  │  3. 派发 worker                          │  │
│  └──────────────────────────────────────┘  │
└──────────────────┬──────────────────────────┘
                   │
                   ↓
┌─────────────────────────────────────────────┐
│           EXECUTION PLANE（执行层）              │
│   planner    researcher    inbox-triage        │
│  workspace   workspace     workspace           │
│   (scratch)   (scratch)    (dir:~/Mail)      │
└─────────────────────────────────────────────┘

三层职责：

• 控制层：用户通过 /kanban 命令或 hermes kanban CLI 与 board 交互
• 状态层：SQLite 是唯一真实数据源；dispatcher 定时扫描 + 原子认领 + 派发
• 执行层：每个 worker 是完整 Hermes 进程（hermes -p <profile> chat -q ...），有自己的 HERMES_HOME、记忆、技能、工作区

关键不变式：永远不允许进程内子 Agent 蜂群。每个 worker 都是独立 OS 进程，通过 board 协调，不直接通信。

四、数据模型

4.1 SQLite Schema

CREATE TABLE tasks (
    id              TEXT PRIMARY KEY,    -- 如 "t_9f2a"
    title           TEXT NOT NULL,
    body            TEXT,                -- 可选的开场帖子
    assignee        TEXT,                -- profile 名，null=未分配
    status          TEXT NOT NULL,       -- todo|ready|running|blocked|done|archived
    priority        INTEGER DEFAULT 0,
    created_by      TEXT,                -- profile 名或 "user"
    created_at      INTEGER NOT NULL,
    started_at      INTEGER,
    completed_at    INTEGER,
    workspace_kind  TEXT NOT NULL DEFAULT 'scratch',  -- scratch|worktree|dir
    workspace_path  TEXT,                -- 认领时解析
    claim_lock     TEXT,                -- host+pid，NULL=空闲
    claim_expires  INTEGER,             -- unix ts，过期认领恢复
    tenant         TEXT                 -- 可选，多租户命名空间
);

CREATE TABLE task_links (
    parent_id TEXT NOT NULL,
    child_id  TEXT NOT NULL,
    PRIMARY KEY (parent_id, child_id)
);

CREATE TABLE task_comments (
    id         INTEGER PRIMARY KEY AUTOINCREMENT,
    task_id    TEXT NOT NULL,
    author     TEXT NOT NULL,    -- profile 名或 "user"
    body       TEXT NOT NULL,
    created_at INTEGER NOT NULL
);

CREATE TABLE task_events (
    id         INTEGER PRIMARY KEY AUTOINCREMENT,
    task_id    TEXT NOT NULL,
    kind       TEXT NOT NULL,   -- status_change|claim|release|error
    payload    TEXT,            -- JSON，诊断用
    created_at INTEGER NOT NULL
);

CREATE INDEX idx_tasks_assignee_status ON tasks(assignee, status);
CREATE INDEX idx_links_child            ON task_links(child_id);
CREATE INDEX idx_comments_task          ON task_comments(task_id, created_at);

4.2 状态机

  todo ──所有父done──→ ready ──原子认领──→ running ──完成──→ done
   │                        ↑                │
   │                        │               block
   │                        │                ↓
   └───────────────── Human/Peer unblock ── blocked
                                                       │
                                                    archive
                                                       ↓
                                                    archived

4.3 Workspace 三种类型

默认是 scratch，因为大多数非编码工作不需要 git。

五、八种协作模式

这些模式全部从基础原语（task + links + comments + assignee + workspace）推导出来，无需扩展 schema。

P1 — Fan-out（扇出）

形态：一个 profile、N 个并列任务、无依赖。

hermes kanban create "angle: cost"     --assignee researcher
hermes kanban create "angle: latency"  --assignee researcher
hermes kanban create "angle: tool-quality" --assignee researcher
hermes kanban create "angle: licensing" --assignee researcher
# → 4个任务全部 ready，并行派发到 4 个 researcher 进程

P2 — Pipeline（流水线）

形态：不同 profile 按序接力，每阶段产出是下一阶段的输入。

T1 (planner) → T2 (scout) → T3 (editor) → T4 (writer)
                  ↑父结果                 ↑父结果
                  feed 进 body            feed 进 body

P3 — Voting/Quorum（投票/仲裁）

形态：N 个 worker 竞速或独立产出，聚合器从中选优。

T1 (analyst)  ← T2(T3(T4(T5  # 4个并行调研
                 ↓
              T6 (aggregator)  # 看到所有父结果，做出裁决

P4 — Long-running journal（长期日志）

形态：同一 profile + 同一 dir workspace + 定时循环任务。

# 每日简报追加到 Obsidian vault
hermes kanban create "daily brief" \
  --assignee analyst \
  --workspace dir:~/Obsidian/AI-Funding/ \
  --schedule "0 9 * * 1-5"

profile 的持久记忆 + 共享目录 → 工作跨次累积，board 作为审计时间线。

P5 — Human-in-the-loop triage（人工介入分诊）

形态：Block → 提问 → Unblock。

# researcher 遇到 gated source，卡住
(hermes) hermes kanban block T3 "source gated; alternative?"

# 用户回复
/kanban comment T3 "use arxiv-sanity mirror"
/kanban unblock T3

# dispatcher 重新派发 worker，worker 读完整评论线程

P6 — @mention delegation（@提及委托）

形态：消息中 @<profile-name> 即隐式创建任务，灵感来自 Google Gemini CLI。

用户："@researcher 帮我调研一下 Gemini 2 的市场表现"
→ 系统解释为：hermes kanban create "调研 Gemini 2 市场表现" --assignee researcher

无需离开聊天界面，board 提供持久化保证。

P7 — Thread-scoped workspace（线程级工作区）

形态：在有线程的消息平台（Telegram群组等），/kanban here 派生任务，其 workspace 绑定到线程关联的本地目录。

多 profile 在同一线程操作时共享工作目录，不打架。

P8 — Fleet farming（舰队扩展）

形态：一个专精 profile + N 并行任务 + 每任务独立 dir。

# 50个 Instagram 账号的社交媒体运营
for i in $(seq 1 50); do
  mkdir -p ~/insta/acct-$i/{assets,drafts,logs}
  hermes kanban create "engage acct-$i" \
    --assignee insta-manager \
    --workspace dir:~/insta/acct-$i/ \
    --tenant acct-$i
done
# → 50个任务同时 ready，50个 insta-manager 进程并行认领

每个账号独立 workspace、独立 tenant 命名空间日志。

六、Orchestrator Profile 模式

6.1 问题

用户反馈（sudo_relax，Nous Discord，2026.04.26）：

"即使创建了 Researcher、Writer、QA 等独立 profile，orchestrator 还是经常自己把活干了。Orchestrator 应该是控制室，不是工作者。"

6.2 三个属性

1. 禁用执行 toolsets

# orchestrator profile
toolsets:
  - kanban      # 只能操作 board
  - gateway     # 只能发消息
  - memory      # 只能读写记忆
# 明确禁用：
disabled_toolsets:
  - terminal
  - file
  - web
  - browser
  - code

它根本没法自己干活，被迫委托。

2. 规范化 orchestrator skill

系统消息简短且规定性：

• "你是调度员，不是工作者"
• "任何具体任务 → 创建 kanban 任务并分配给专家 profile，不尝试执行"
• "如果没有任何专家适合，问用户该创建什么 profile，不要默认自己来干"

3. 标准专精 roster 约定

6.3 可安装 profile 模板

hermes profile install orchestrator  # 调度员
hermes profile install researcher    # 专家们
hermes profile install writer
hermes profile install analyst
hermes profile install reviewer
hermes profile install ops
# → 舰队上线，随时待命

这是 Paperclip"公司模板"思路的轻量化实现，同时关闭了 Gemini subagent-as-file 的功能差距。

七、多租户支持

7.1 最小化 schema 变更

ALTER TABLE tasks ADD COLUMN tenant TEXT;  -- 可选，默认为 NULL
CREATE INDEX idx_tasks_tenant ON tasks(tenant);

一个可选列，所有隔离逻辑从中导出。

7.2 四轴隔离

7.3 共享的部分

• Profile 身份：一个 researcher profile 存在，被不同 tenant 复用
• Dispatcher：一个 cron job、一个 board、所有 tenant 共用
• Orchestrator：同一 orchestrator 实例给所有 tenant 分配任务，自动向下传播 tenant 到子任务

7.4 "小公司服务多客户"问题

researcher profile (同一个)
    │
    ├── --tenant business-a → ~/tenants/business-a/data/
    └── --tenant business-b → ~/tenants/business-b/data/

一个 researcher，两个业务上下文。边界由文件系统路径和内存前缀 enforcement 保证，无需新增实体类型。

八、Kanban vs. delegate_task（边界划分）

这是整个设计的核心问题。

一句话区分：delegate_task 是函数调用；Kanban 是一个持久化工作队列，每一次交接都是一行数据库记录，任何 profile（或人）都能看到和编辑。

决策树：

• 用 delegate_task：父需要子结果才能继续；子任务是自包含短推理；秒到分钟级；无人介入；结果回到父上下文
• 用 Kanban：跨 Agent 边界交接；需跨重启持久化；可能需要人工输入；可能由不同角色接力；完成后需可发现

两者共存：Kanban worker 内部仍可调用 delegate_task 做内部推理，这是正常预期。

九、Dispatcher 设计

9.1 刻意设计的"哑巴"dispatcher

Dispatcher 只有三个操作：

1. 重算 ready：对每个 todo 任务，若所有父链接都到达 done，转为 ready
2. 原子认领：对每个 ready + claim_lock IS NULL + assignee IS NOT NULL 的任务，执行 CAS
3. 派发 worker：解析 workspace，执行 hermes -p <assignee> -w <workspace> chat -q "work kanban task <id>"
4. 过期回收：对 running + claim_expires < now 的任务，重置为 ready

9.2 并发正确性

BEGIN IMMEDIATE;
UPDATE tasks
SET status = 'running',
    claim_lock = :host_pid,
    claim_expires = :now + 900,
    started_at = :now
WHERE id = :id
  AND status = 'ready'
  AND claim_lock IS NULL;  -- CAS 条件
-- changes() == 1 → 赢；== 0 → 输，继续
COMMIT;

SQLite WAL 模式 + BEGIN IMMEDIATE 事务 + 行级 CAS，最多只有一个认领者能赢。

9.3 智能路由不在内核

"智能路由"、"自动分配"、"优先级队列" 全部是用户空间 concerns，可以通过一个 router profile 实现，无需改动 dispatcher：

# router profile 的工作：扫描 unassigned tasks，重新分配
hermes kanban list --status ready --assignee null
hermes kanban assign <id> <best-profile>

十、CLI 命令表面

hermes kanban init                              # 创建数据库
hermes kanban create "<title>"                  # 创建任务
       [--body ...]                             #  附言
       [--assignee P]                          #  分配给某 profile
       [--workspace K]                          #  scratch|worktree|dir:<path>
       [--tenant T]                            #  多租户命名空间
       [--parent <id>]                         #  设置父任务（自动建立链接）

hermes kanban list [--mine] [--assignee P] [--status S] [--tenant T] [--json]
hermes kanban show <id>                         # 详情+评论+事件
hermes kanban assign <id> <profile>            # 分配/重分配
hermes kanban link <parent> <child>             # 添加依赖
hermes kanban unlink <parent> <child>          # 移除依赖
hermes kanban claim <id>                       # 手动原子认领
hermes kanban comment <id> "<text>"            # 追加评论
hermes kanban complete <id> [--result "..."]   # 标记完成
hermes kanban block <id> "<reason>"            # 阻塞
hermes kanban unblock <id>                     # 解阻塞
hermes kanban archive <id>                     # 归档
hermes kanban dispatch                          # 手动触发一次 dispatcher 扫描

十一、实现计划（8个独立 PR）

零改动范围：run_agent.py、model_tools.py、toolsets.py、agent/ 目录——全部不受影响。

十二、刻意不做的功能

十三、风险管理

十四、总结

Hermes Kanban 的本质是一个最小化协作内核：

• 1 个 SQLite 文件
• 1 个 CLI 子命令
• 1 个 skill
• 1 个 cron job
• 零内核改动

所有复杂功能（编排、多租户、审批、仪表板）都在用户空间 profiles 和 plugins 里实现——即使这些功能崩溃，也不会动摇协作结构本身。

和 delegate_task 的关系：共存、不互斥。判断标准只有一条：

这次交接是否需要跨单次 API 循环存活并对他人可见？
是 → Kanban；否 → delegate_task

参考：hermes-kanban-v1-spec.pdf，Nous Research，2026年4月25日，Revision 01